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Comments on memory allocation control commands 
CEASE, ALL, GVB, RET) and RFNM 


The protocol provides a scheme for buffer allocation. This scheme is 
rather complicated because it necessitates two parallel mechanisms. 


It is not obvious that both are necessary. In fact it is suggested 
that this scheme could be probably replaced by a slightly different 
conception of the Request for Next Message (RFNM). Now the RFNM is 


sent back from the receiving imp after the message has been 
reconstituted and the first packet transmitted to the host. Nothing 
insures that the whole message has been accepted and correctly 
received by the host; also the design of the host imp interface 
permits the host to stop accepting data from the imp during any length 
of time; as the link has been already unblocked by sending back the 
RFNM another message may be transmitted by the sending foreign host 
which will congest the imp’s memory. On the other hand it is prob- 
able that usually the host is able to accept data from the imp at a 
higher rate than it is transmitted on the network, e.g. 200k bits/sec; 
thus the time to transmit a full message from the imp to the host 
would be approximately 1/20th of a second which is 10 times less than 
the average delay of transmission of a message over the network. This 
indicates that to send a RFNM after the reception of a full message by 
the host would not increase significantly the response time on the 
network. 


In this case there is no reason why the RFNM could not be initiated by 
the receiving host as an acknowledgment of the correct reception of 
the message (ACK), and take the form of either a host imp or a control 
command message. This RFNM could have the two forms 


ACK (CONTINUE) 
or ACK (CEASE) 


This would permit to add to the message some error detection 
redundancy, such as check sum bits as proposed in [DELO 69]. In the 
present design nothing insures that one or several bits of the text 
has not been altered, e.g., by an interference or a deficiency of one 
of the host imp interfaces. This could have important consequences, 
e.g. if the text is used to update a centralized data base. Also, if 
the user has a way of detecting the error, but none of correcting it, 
it has no way of asking for the retransmission of the message, which 
has probably been discarded at the sending end upon reception of the 
RFNM. In fact it seems not up to the user to have to detect errors in 
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its text but rather up to the NCP: the user process must as much as 
possible act as if it was talking to some other local process. Soa 
third kind of RFNM sent by the NCP could be: 


NAK (REPEAT) 
Repetition would also be initiated in case of no reply. 
Thus we see that it seems worthwhile to make these slight 
modifications which would permit to use between the sending host and 


the receiving host a very simple point-to-point transmission procedure 
which would insure control of the data transmitted from end-to-end. 


It could also replace the memory allocation mechanism: ACK (CONTINUE) 
would only be sent if space was available for a new message on this 
connection and/or ACK (CEASE) would be sent if no more space was 
available; it corresponds to the WABT of classic transmission 
procedures [USAS69]; transmission could be resumed by an ACK 
(CONTINUE) or a RESUME from the receiving end. The user process is 
not mixed at all with this memory allocation which is a function of 
the system (or NCP): it only sees a varying global transmission speed 
of its data on a connection. The imp programs take care of the 
routing of the data according to the distributed nature of the 
network, and neither the user nor the system (or NCP) is concerned 
with it. Other improvements to the protocol may be found after 
experiencing it. 


Finally note that this solution does not immobilize the imp memory any 
longer than the actual solution, because it is not the imp which has 
to repeat a message, but the sending host. 
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